home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19990725-20000114
/
000450_news@columbia.edu _Thu Jan 13 01:24:50 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
2KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id BAA00440
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 13 Jan 2000 01:24:50 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA06497
for kermit.misc@watsun.cc.columbia.edu; Thu, 13 Jan 2000 00:57:53 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
Subject: Re: MS-DOS Kermit, more capabalities
From: cangel@famvid.com
Message-ID: <cPdf4.3607$KP.188008@tw12.nn.bcandid.com>
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Thu, 13 Jan 2000 05:57:28 GMT
To: kermit.misc@columbia.edu
On 1900-01-07 jrd@cc.usu.edu(JoeDoupnik) said:
JD>> FD> Is there no way to free the memory for additional
JD>> FD> 'take' commands to be used or does it just load up one
JD>> FD> time and thats it?
JD>Take command files are literally Kermit commands, one after
JD>the other. The file is not stored in Kermit, the lines are read and
JD>processed one at a time. Macros and variables result in storage,
JD>however, and there are limits on their quantity. Storage for values
JD>of them are taken from DOS free memory. An MS-DOS Kermit command
JD>line works in a buffer and hence has physical limits (1000 bytes
JD>in round numbers).
With such a rich macro language it would be `nice' to be able to reuse
the available memory so that more complex macros could be written and
used while online without an `exit / reload' being required.
While I have your attention: I've been compiling and fiddling with the
WATTCP package which claims to have a part of it's code inside MSKermit.
MSKermit is many times more stable than the demo apps that come with the
WATTCP source (operation online is `intermittent' with send being exremely
poor and receive seems locked into something less than 9k6). MSKermit
OTOH seems to move right along using the same packet driver and achieves
90% of theoretical max transfers on a regular basis.
Question: could you direct me to any particular part of the WATTCP based
code in the MSKermit source that would reveal how MSKermit seems to be
so much better than the `origninal'?
BTW: I know what the `UUE' extension is but what is the `BOO' extension
used on the v315 source code zip files?
Charles.Angelich